1. Field of the Invention
Embodiments of the present invention relate in general to the field of electronic circuits, in particular to computer software methods of detecting errors in electronic circuit designs.
2. Description of the Related Art
Electrical engineers often need to verify that a circuit will function properly, before it is fabricated as an integrated circuit. The most common way of doing this is to use simulation software, such as SPICE. However, there are many situations where an electrical circuit may have potential faults that will not be detected or predicted by simulation. Hence, the engineer often wants to employ additional checking on the circuit, using topology as an alternative to time domain simulation.
One of the most common types of circuit checks is to verify that a particular device, such as a transistor, is adequately (not improperly) connected. Standard industry practice is to subject a circuit design to peer review, wherein one might discover, upon inspection of schematics, that a transistor may be connected to a source of voltage that is too high for the ratings of that particular given device. Other common circuit checks include: inspection of transistor gate terminals to make sure they're tied to valid signals, inspection of power supply nets to make sure they're not shorted to ground nets, inspection of signal outputs to make sure they're driving the appropriate inputs elsewhere, and so on.
Modern electronic circuits, such as integrated circuit chips can often be composed of hundreds of millions of electrical components. These can include a diversity of electronic devices (e.g. field effect transistors (FET), metal oxide semiconductor field effect transistors (MOSFET), bipolar junction transistors (BJTs), and other sub-circuits, often formed from various types of simpler transistor-based circuits. Such chips are highly complex to both design and debug. As a result, there has been a substantial amount of prior art interest in both computer software methods to design complex electronic circuits, and as computer software methods to simulate the function of these complex electronic circuits.
A “net” is a term for a circuit connection that ties multiple electrical device pins together (in math terms and graph traversal terms, this is called a “node”). A whole circuit consists of many such nets (e.g. net1, net2, net3 . . . netn). When a circuit is represented in the form of a computer storage file, it is usually called a “netlist”. It is usually easier to at least begin analyzing more complex electronic circuits at the netlist level, and thus the computer software used to analyze such electronic circuits is sometimes referred to as “netlist analyzers”.
One of the most common electronic devices in circuits is the field effect transistor, or “FET”. A FET can generally be thought of as providing a valve or regulatory function, where the amount of current passing through the device is controlled by its gate terminal, or “gate”. Because gates are the controlling points of the regulatory functions that FETs provide, they are of critical importance in the operation of a circuit.
As might be imagined, when highly complex integrated circuit chips are designed, their complexity soon outstrips the ability of both the human mind (and even sophisticated computer circuit design software) to understand and detect all design problems. One design problem that has been particularly difficult for prior art methods to detect and analyze is when, often due to an unintended design oversight, floating FET gates, essentially non-functional or improperly functioning portions of the circuit, are created. In a sense floating gates act somewhat like uninitialized variables in software, because their function is unpredictable (they control FETs in an unpredictable way). Floating gates can cause a complex circuit to either fail outright or act in an erratic and undesired manner.
In the typical electronic circuit, almost all nodes have at least some DC (direct current, or current-conducting) pathways, usually through devices such as transistors or resistors, to other nodes. In unusual cases, a circuit node will exist that does not have such DC pathways, or has only DC pathways that are of an impedance that is high enough that no significant current flow can take place to or from that node. These infinite-impedance or high-impedance nodes can be thought of as isolated, or “floating” nodes. A node is floating if it does not have a path that can source or sink any significant amount of current to or from other parts of the circuit, ultimately reaching one or more power supplies in the circuit. Furthermore, two or more nodes may form a floating island together, where such nodes have DC pathways between them, but no significant DC pathways to other parts of the circuit. Thus, a floating node may exist by itself, or may exist in conjunction with others. Floating nodes can be time dependent, where at some time (e.g. some circuit clock cycles, or during some time-dependent circuit sates) a DC path to or from the node is interrupted and can no longer conduct significant current.
Floating gates generally can arise when a transistor gate (gate) is not connected to any source of direct current, such as a driver (e.g. the gate may be connected to another gate or various passive devices, but there is no DC path between the gate and the circuit power or ground). Floating gates can also arise when the signal path to a gate is cut, for example by a transfer switch that has been cut off, or when driver power to the gate is disabled. Floating gates are a risk in the circuit industry, for one floating gate in an otherwise properly designed integrated circuit chip may cause reduced functionality or even permanently kill a circuit.
What makes floating gates particularly hard to detect is that often such portions of the circuit only float, i.e. become high-impedance, under certain conditions (e.g. high-impedance conditions). Under other conditions the circuit may operate normally. Even if the high-impedance conditions are reached, the circuit may still not show any apparent symptoms of failure at that time, because the very nature of floating gates is to manifest random behavior.
Another factor that makes floating gates difficult to both detect and analyze is that often, particularly with complex circuits, a design feature (e.g. a root “cause”) in one part of the circuit tends to create a floating gate (e.g. an undesired “effect”) in another part of the circuit. When the “cause” and “effect” are close together, the problem is easier to spot, but as they become more remote from each other, the problem becomes harder and harder for prior art circuit analysis or netlist analyzer tools to detect.
Because large circuits have a complexity that goes beyond the scope of what can normally be inspected by humans during schematic review, it is common practice for an engineer to employ programming techniques (e.g. software program based analysis methods) to accelerate circuit inspection, by using the circuit netlist or schematic to perform automated processing and analysis. Indeed, various prior art circuit design and analysis software programs (such as the open source, non-proprietary Gnu EDA, www.gpleda.org) provide utilities to form a circuit database and execute queries on the circuit structure, such as to check connections. Furthermore, using prior art methods, an engineer may create a script based on PERL, Tcl, or similar language to read a netlist directly and look for invalid constructs or connections. Examples of such code are also known and can be widely found on the internet.
Thus although there are various types of prior art software simulation methods, exemplified by the popular SPICE software family, which can take as inputs a description of a circuit (e.g. a net list) as well as a description of a particular type of defined test procedure (i.e. a set of test vectors), these prior art software simulation methods are limited in that if the proper series of tests (test vectors) is not run, then problems such as floating gates may be missed. Unfortunately, it is often far from obvious to determine what the optimal set of test vectors are for any given circuit, and thus at present, floating gate problems are often missed, resulting in much wasted time and resources. Thus improvements in software computer circuit analysis are desirable.